1. Field of the Invention
The present invention relates generally to the field of distributed computing and, more particularly, to a methodology supporting “piggybacked” reflective callbacks.
2. Description of the Background Art
Distributed computing is a type of computing in which different components and objects comprising an application can be located on different computers connected to a network. With the explosive growth of the Internet, distributed computing has become increasingly popular in order to simplify network programming and to realize component-based software architecture. To support distributed computing, an object framework or model is defined, thereby specifying a set of standards about how objects communicate with one another. Currently, two chief distributed computing standards exist: CORBA and DCOM. Each will be briefly reviewed in turn.
CORBA, short for Common Object Request Broker Architecture, is a distributed object model proposed by the Object Management Group (OMG), an industry consortium. Central to the CORBA architecture is the “Object Request Broker” (ORB) that acts as an “object bus” over which objects transparently interact with other objects located locally or remotely. A CORBA object is represented to the outside world by a defined interface with a set of methods. A particular instance of an object is identified by an object reference. The client of a CORBA object acquires a corresponding object reference for use as a handle to make method calls, as if the object were located in the client's own address space. The ORB is responsible for all the mechanisms required to find the object's implementation, prepare it to receive the request, communicate the request to it, and carry the response or reply (if any) back to the client. The object implementation interacts with the ORB through either an Object Adapter (OA) or through the ORB interface. In this manner, CORBA enables pieces of programs (i.e., components or objects) to communicate with one another regardless of what programming language they were written in or what operating system they are running on.
DCOM, short for Distributed Component Object Model, represents Microsoft's distributed object model. It is implemented as an extension to Microsoft's Component Object Model (COM). DCOM adds an object remote procedure call (ORPC) layer on top of Distributed Computing Environment's remote procedure call mechanism (DCE RPC) to support remote objects. A COM server can create object instances of multiple object classes. A COM object can support multiple interfaces (sets of functionally related methods), each representing a different view or behavior of the object. A COM client interacts with a COM object by acquiring a pointer to one of the object's interfaces and invoking methods through that pointer, as if the object were located in the client's address space. COM specifies that any interface must follow a standard memory layout, which is the same as the C++ virtual function table. Since the specification is at the binary level, it allows integration of binary components possibly written in different programming languages such as C++, Java and Visual Basic. However, unlike CORBA, which runs on many operating systems, DCOM is targeted for use with Microsoft Windows.
Both DCOM and CORBA frameworks provide client-server type of communications. To request a service, a client invokes a method implemented by a remote object, which acts as the server in the client-server model. The service provided by the server is encapsulated as an object and the interface of an object is described in an Interface Definition Language (IDL). The interfaces defined in an IDL file serve as a contract between a server and its clients. Clients interact with a server by invoking methods described in the IDL. The actual object implementation is hidden from the client.
In both DCOM and CORBA, the interactions between a client process and an object server are implemented as object-oriented RPC-style communications. To invoke a remote function, the client makes a call to the client stub. The stub packs the call parameters into a request message, and invokes a wire protocol to ship the message to the server. At the server side, the wire protocol delivers the message to the server stub, which then unpacks the request message and calls the actual function on the object.
Both DCOM and CORBA include a middle layer that functions to provide the client and the server with the illusion that they are in the same address space. The main differences between DCOM and CORBA at this layer include how server objects are registered and when proxy/stub/skeleton instances are created. To send data across different address spaces requires a process called marshaling and unmarshaling. Marshaling packs a method call's parameters (at a client's space) or return values (at a server's space) into a standard format for transmission. Unmarshaling, the reverse operation, unpacks the standard format to an appropriate data presentation in the address space of a receiving process.
In distributed computing environments, actual method invocation can be performed in a forward or backward manner. Forward-calling technique, which entails simply invoking a function or method on a target, is a rather straightforward approach for developers to use for the purpose of invoking remote functionality. However, the technique has the disadvantage in that it limits the scalability of one's system. Backward calling technique, in contrast, can improve system scalability. However, developers may not be as comfortable with callback technique as they are with forward calling technique. The term “callback” is often used to describe a function or method call made in a backward direction, with the term “call” being used to simply refer to a forward call. The direction is defined quite arbitrary based on application model and therefore meanings of call and callback are purely relative. Also, in object-oriented systems, call (i.e., forward call) and callback are all made on the target or “callee” object's type safe interfaces to generate a semantic result on the callee. When a call is made backward, the semantic result is also intended to be backward.
In many application scenarios, it is necessary to employ a backward invocation to generate a semantic result as if a forward invocation were made. This type of backward invocation is referred to as a “syntax callback” to differentiate it from normal relative callback and to also indicate that, in this backward invocation scenario, the actual intended semantic result is forward.
Syntax callbacks are widely used in distributed software systems, typically to retrieve (i.e., “pull”) a request or deliver a reply. For example, in object-oriented event replicating/distributing service, such as OMG CORBA typed event services, strong typed events are defined as operations of an interface. Invoking operations of this interface, by active event suppliers on a remote channel object, will push (typed) events into the channel. This channel also forwards these events by invoking the same operations on remote passive consumer objects. Now, as a widely used reverse event delivery scenario, channel also needs to support a backward pulling model. In the backward pulling model, the channel will callback passive suppliers to pull events out from them as if events are actively pushed into the channel. Active consumers also call back to the channel to pull events back as if they are pushed from channel. As another example, in object-oriented remote asynchronous invocation, such as OMG CORBA Messaging, a request router needs to forward a typed invocation to a specified target object and, then, deliver its reply back to a specified passive reply receiver using a callback.
Presently, there exist two approaches to deal with syntax callback in an object-oriented framework. The first approach is to define a “mangled” interface from the original forward version interface. The mangled interface maps the return value into a first input parameter, maps any exception as a separate signature, and maps the input parameter(s) to output (and vice versa). Then, the active consumers use the mangled interface, the passive supplier, and the asynchronous reply receiver to implement it. This is the approach taken by OMG typed event service and OMG Asynchronous Messaging.
However, the approach is problematic. In most real world applications, mangling an interface immediately defeats the purpose of having an interface. Except for very few trivial cases, mangled interfaces are very difficult to use. Interface definition language (IDL) to programming language mappings need to be extended for each targeted language to support this interface mangling. Language mapping tools (IDL to C++, IDL to Java, etc.) have to be modified to be able to automatically generate the mangled interface. Because the callback uses a mangled interface different from the interface used by forward calling model, the change to the calling model without changing the interface also means massive code changes.
The second approach is to simply abandon the object-oriented interface definition and retreat to a message-oriented paradigm. This is the solution seen in Java Message Service (JMS) and OMG structured notification. The approach is also problematic. A message oriented paradigm usually has a much lower abstraction level than a corresponding object oriented paradigm and, therefore, results in a large semantic gap that has to be filled by application developers. Type safety is also sacrificed. Code is more error prone and less “modular” in organization. Message oriented systems tend to have undesirable strong coupling among software components than object-oriented system. Additional manual code is required to pack/unpack messages. For content rich messages, message sizes are substantially larger than their typed counterparts. For example, for the same ITU-T X.780 CORBA/TMN event, a structured message size is around 300% of its typed counterpart.
Given that, a problem presents itself: how does one support syntax callback by an object-oriented distributed framework (e.g. CORBA, J2EE, etc.)? In other words, how can one employ callback technique for an interface that was originally defined for forward calling technique? With the ever-increasing use of distributed systems, there is much interest in providing a solution to this problem.